Method of communication between a user station and a network, in particular such as internet, and implementing architecture

ABSTRACT

A method and architecture for communication between a terminal ( 1 ) and a smart card, said terminal being operatively connected to a smart card reader ( 3 ) and a data transmission network (RI). The terminal includes an initial stack of network (RI) access protocol which consists of a specified number of communication software layers (C 1 -C 4 ). The said smart card ( 3 ) and said smart card reader comprise second and third protocol stacks, each consisting of at least lower order software communication layers (CC 2 -CC 1 , CCa 2 -CCa 1 ), in order to allow data exchange between the smart card and said terminal ( 1 ). In a first preliminary phase, a first specific software item ( 23   a ) smart card ( 2   a ) functions as an interface for the lower layers (CCa 2 -CCa 1 ) of the third protocol stack and with at least one application ( 24   a ) registered in the smart card ( 2   a ). In a second preliminary phase, a second specific software item ( 13 ), functions as an interface with said lower layers (CC 2 -CC 1 ), of the second protocol stack and with specified layers of said first protocol stack (C 2 , C 3 ), and is installed in the terminal ( 1 ). The first and second specific software items ( 13 , and  23   a ) in addition comprise at least one pair of primary coupled software entities ( 132, 232   a ). Each of the entities ( 132  and  232   a ) cooperate with each other in order to allow for the establishment of a bi-directional data exchange session between the terminal ( 1 ) and said smart card ( 2   a ) and/or said data transmission network (RI), so that all or part of said data travels through said smart card ( 2   a ). The smart card may supply the terminal ( 1 ) with a predetermined virtual model which transforms the smart card ( 2   a ) into a server and/or client.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method of communication procedurebetween a user station and a data transmission network, using anInternet-type protocol.

The inventive procedure pertains in particular to a user stationequipped with a “smart” card reader and connected to the aforementionednetwork.

This invention also relates to the system architecture forimplementation of the method.

2. Definitions

Within the scope of this invention, the common meaning of the term “userstation” is upheld. The aforementioned station may, in particular,consist of a personal computer using various operating systems such asfor example, the WINDOWS or UNIX type (both copyrighted). It may alsoconsist of a dedicated worksation, a portable computer or a cardterminal.

Similarly, within the scope of this invention, the term “Internet”encompasses, in addition to the Internet itself, all private businessnetworks or other networks, termed “intra-nets”, as well as networkextensions, termed “extra-nets”.

In the following, without limitation to any kind of applications, thescope will refer to a preferred application of the invention, exceptwhen otherwise specified. Thus, a user station, termed simply “Terminal”is equipped with a smart card reader and connected to an Internet-typenetwork, is considered.

An application system, based on a smart card, in general consists of thefollowing main components:

a smart card;

a host system consisting of the aforementioned Terminal;

a communication network, and specifically the Internet, for thepreferred application;

an application server connected to the network.

DESCRIPTION OF RELATED ACT

FIG. 1 illustrates an example of this type of system architecture.Terminal (1), for example, a personal computer, comprises a smart card(2) reader (3). The reader (3) may or may not be physically integratedto terminal (1). The smart card (2) comprises an integrated circuit(20), the input-output connections of which show through the surface ofthe case to allow for electrical power supply and communication with theterminal (1). The latter comprises access circuits to a datatransmission network (RI). These circuits depend, in particular, on thespecificity of network (RI) and terminal (1). On an exemplificationbasis, it could consist of a network card for local area type networks,or a modem for connection to a dial-up telephone line, or an integratedservices digital network (ISDN), for connection to the Internet, forexample, via an Internet Service Provider (ISP).

Terminal (1) obviously comprises all the circuits and componentsrequired for proper operation, which are omitted for purposes ofsimplification in the figure. These circuits and components includecentral unit, read-write and fixed storage memory, magnetic disc memory,disc and/or CD ROM driver, etc.

Additionally, it is also customary for Terminal (1) to be linked totraditional peripherals, integrated or not, such as a monitor (5) and akeyboard (6).

Communication may be established between Terminal (1) and serversconnected to the network (RI), one of which (4) is illustrated in FIG.1. For the case of the preferred application of this invention, accesscircuits (11) establish communication between terminal (1) and theservers (4) using a particular software (11), termed navigator or“browser”. The latter allows for access to different applicationsdistributed across network (RI) and, in general, according to a“client-server” mode.

Usually, network communication occurs according to protocols consistentwith specific standards and comprising several superimposed layers ofsoftware. For the case of network (RI) of the internet type,communication occurs according to specific protocols compatible withthis type of communication, which will be subsequently described indetail, although they also consist of several software layers. Acommunication protocol is selected depending on the specific applicationthat is targeted: for example querying of “WEB” pages, file transfer,electronic mail (e-mail), forums, “news” etc.

In an application system that is smart card based, as illustrated by thearchitecture of FIG. 1, the smart card may be ascribed severalfunctions. In particular, it is used for security purposes:confidentiality and/or authentication of the terminal (1) user.

However, it should be noted that card (3) cannot communicate withcommercially available navigators unless the latter's code is modified.Current smart cards, which are otherwise consistent with specificstandards, contain both software and physical configurations, which alsodo not allow for direct communication with the Internet. In particular,they cannot receive or transmit data bundles, according to protocolsused by this kind of network. Thus, there are provisions for inclusionof an additional piece of software installed in terminal (1), ingeneral, referred to as a “plug-in”, according to Anglo-Saxonterminology. This piece of software, referred to in FIG. 1 as (12),functions as an interface between navigator (10) and card (2) and, inparticular, the electronic circuits (20) of card (1) therein.

Card (2) supplies data for navigator (10), in particular security data:for example, data that allows identification or authentication, or evendata access authorization for any one of the remote servers (4), and/orapplications located on the servers.

This procedure affords a greater level of security than usage alone ofsecurity software layers, and supplied recently by some navigators.Smart card (2) remains the property of the user and under the user'scontrol. In particular, all security data stays in the smart card (2)memory and is only transmitted to the terminal (1) in numerical format.However, this security chain does present a weak “link”. That is,navigator (10) is in communication with the outside world. Thus, inreality, communication is indirect, as it occurs, in particular, viaaccess circuits (11) and via different software layers, which will bedescribed subsequently in greater detail. However, the terminal (1),which is usually used for this type of application, does not include anyspecific means, whether physical or software, that can afford a highlevel of security and isolate it from the outside world. Thus, itremains vulnerable to different attacks from network (RI): “viruses”,“Trojan horses”, “logic bombs” etc., even despite the presence of cardreader (3) and smart card (2), peripheral to Terminal (1).

Finally, smart card (2) may be used for applications other than forsecurity. It is important to note that, given the state of the art, thehost system linked to the smart card reader (3), that is terminal (1),is also linked to a particular kind of application. In other words,provisions are required for dedicated task specific terminals for eachparticular application.

Further, there are currently numerous needs for applications based onsmart cards, needs that are either imperfectly or completely unsatisfiedby the present state of the art, whose main characteristics have beenoutlined above. Otherwise, there are also certain needs and requirementsthat are contradictory to these characteristics.

The following list of needs is non-exhaustive:

personal mobility: users need to be able to access communicationservices anywhere in the world, either using their own equipment orusing equipment that is compatible with their smart cards, and thus witha degree of specified communication security;

standard environment: wherever users are, they need to be able to findaccess to their own work environment, with the benefit of communicationsecurity as mentioned above, in other words, the process of changingequipment needs to be “transparent” for users;

terminal mobility: the terminal itself needs to be portable andconnectable to any segment of the network, with users benefiting fromall possibilities (authorized access, etc.) regularly available at theirown sites;

multifunctionality and standardization: Terminals in use should becapable of accepting multi-functional smart cards, which implies thatthey are no longer required to be dedicated or that they at leastrequire downloading or installing of additional software (“plug-ins”etc.) specific to each application.

SUMMARY OF THE INVENTION

This invention is designed to compensate for disadvantages identified inthe state of the art, several of which have been mentioned, whilesupplying a high level of communication security and responding to needsand requirements that are currently sensed in this domain.

According to one essential characteristic of this invention, all or partof the bi-directional flow of data between terminal and network isgenerated by the smart card, in order to isolate the terminal from theoutside world. For this purpose, at least part of the aforementionedsoftware layers for protocols are installed in the smart card.Additionally, provisions exist for installation of a specific layer ofcommunication software in the smart card, with its counterpart in theterminal. The term “specific” is to be understood as specific to theinvention procedure. Thus, these specific communication layers, becomeall-purpose, regardless of the considered application. They onlyintervene during the exchange process of bi-directional data between theterminal and the smart card, on the one hand, and between the smart cardand the network, on the other.

Specific communication software layers consist, in particular, ofsoftware agents, termed “intelligent agents”, allowing in particular forprotocol conversion. There are agents coupled to specific communicationlayers, respectively linked to the terminal and the smart card.According to the inventive method, sessions are opened between coupledagents.

Consequently and, in particular, all communication security functionsare processed solely from the within the smart card, rather than fromwithin the terminal. The smart card no longer transmits keys or otherstored and secret data to the terminal in any form whatsoever, evennumerical, according to the state of the art (FIG. 1).

However, according to another feature of this invention, the smart cardcan authorize direct links between the terminal and, in particular, thenavigator, for Internet-type transmissions and the network, for example,for data that requires security processing (graphic or image data of“WEB” pages etc.).

According to another characteristic of this invention, the smart cardsupplies the host system, that is, the terminal, with a virtualterminal, for example, as a page in “HTML” (HyperText Markup Language)or, in general, in hypertext format, or even as a software item termed“applet” in JAVA (Copyrighted) language, which allows the user to selecta particular application among those available and offered by the smartcard. Thus, the terminal becomes all-purpose as it supports numerousapplications. The host system is seen as peripheral to the smart card,supplying physical resources such as a monitor for visualization, akeyboard, etc.

This invention thus relates to a method of communication between aterminal, equipped with a smart card reader and a data transmissionnetwork, said terminal containing an initial protocol access stack tothe network, which consists of a specific number of communicationsoftware layers, and said smart card reader, said smart card comprisingsecond and third protocol stacks, each consisting of at leastcommunication software layers, termed lower, in order to allow dataexchange between the smart card and said terminal, wherein it comprisesan initial and preliminary phase for installing, on the smart card, aspecific software item, which functions as an interface between saidlower layers of the third protocol stack and at least one registeredapplication of the smart card, wherein it comprises a second preliminaryphase for installing a specific software item, which functions as aninterface between said lower layers of the second protocol stack andspecific layers of said initial protocol stack, wherein said first andsecond specific software items additionally consist of at least one pairof initially coupled software entities, each of said entitiescooperating with the other in order to allow for a bi-directional dataexchange session to be opened between said terminal and said smart cardand/or the network, so that all or part of said data travels throughsaid smart card.

This invention also relates to a method of communication between aterminal equipped with smart card reader and a data transmissionnetwork, said terminal comprising an initial protocol access stack tothe network, which consists of a specific number of communicationsoftware layers, and said smart card reader, said smart card consistingof the second and third access protocol stacks, each consisting of atleast software communication layers, termed lower, in order to allowdata exchange between the smart card and said terminal, wherein itconsists of an initial preliminary phase to install, on the smart card,an initial specific software item, which functions as an interfacebetween said lower layers of the third protocol stack and at least oneregistered application of the smart card, wherein it consists of asecond preliminary phase to install on the terminal a second specificsoftware item, which functions as an interface between said lower layersand the second protocol stack and with specific layers of said firstprotocol stack, wherein said first and second specific software itemsadditionally consist of at least one pair of initially coupled softwareentities, each of which entities cooperating with the other in order toallow for a session of bi-directional data exchange to be opened betweensaid terminal and said smart card, so that said smart card supplies saidterminal with a model terminal, termed virtual, that transforms thesmart card into a server and/or client.

This invention additionally relates to system architecture for theimplementation of the procedure.

It is easy to observe that this invention clearly offers numerousadvantages. It offers, in particular, high level of security forcommunication between terminal and network. It creates an all-purposeterminal, which allows it to support numerous applications withouthaving to modify either physical components of the terminal or any ofthe applications running inside the terminal. All that is required is toinstall a specific communication software layer, which may be performedonce permanently or via uploading, as many times as required fromdifferent sources: diskettes, CD-ROMs, downloading etc. It remainscompletely compatible with existing equipment and its implementation. Asan example, when a user does not want to benefit from the possibilitiesand advantages of this invention, or if she/he does not own a smart cardconsistent with this invention, it is still possible to use the terminaland associated navigator, as well as a traditional smart card, in aconventional manner, that is, as described in reference to the system inFIG. 1.

BRIEF DESCRIPTION OF THE DRAWINGS

This invention will be better understood and other characteristics andadvantages with become clear following the description below, inreference to the appendix Figures, among which:

FIG. 1 schematically illustrates an example of system application basedon smart cards according to the current state of the art;

FIG. 2 schematically illustrates an example of a system applicationbased on smart cards according to an initial feature of this invention;

FIGS. 3A-3C schematically illustrate additional aspects of thisinvention;

FIG. 4 schematically illustrates the complete architecture of a terminalequipped with a smart card reader, according to this invention;

FIG. 5 schematically illustrates a protocol stack for communicationlayers, according to this invention;

FIGS. 6A and 6B schematically illustrate two examples of data exchangebetween a smart card, a terminal of FIG. 5 and an outside network;

FIGS. 7A to 7D schematically illustrate, in box diagram format, variousdifferent system architectures, consistent with this invention; and

FIG. 8 schematically illustrates a particular software configuration forthe smart card.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Prior to describing the method of communication of this invention andproviding a detailed description of the architecture for implementation,it appears of interest to briefly summarize the main features ofexisting communication protocols for networks.

The architecture of communication networks is described in terms ofvarious layers. As an example, the “OSI (“Open System Interconnection”)standard consists of seven layers ranging from layers, termed lower (forexample the layer termed “physical” which pertains to support forphysical transmissions), to layers, termed higher (for example the layertermed “application layer”) and intermediate layers, in particular, thelayer termed “transport layer”. Any given layer offers services to alayer that immediately succeeds it and requires from the preceding layerother kinds of services, via an appropriate set of interfaces. Layerscommunicate with each other using primitives. They can also communicatewith layers on an intra-level basis. In certain architectures, one layeror another may be missing.

In the Internet environment, there are five layers and, in particular,from the highest layer to the lowest: an application layer (“http”,“ftp”, “e-mail” etc.), a transport layer (“TCP”), a network addressinglayer (“IP”), a data link layer (“PPP”, “SLIP”, etc.) and the physicallayer.

Following this brief outline, we now proceed to the description of anapplication system architecture, based on an inventive smart card. Anexample of such an architecture is represented schematically in FIG. 1.Elements common to FIG. 1 are referred to in identical ways and are notdescribed anew, except when required. To simplify the Figure, variousperipherals connected to the terminal have been omitted (for example,from FIG. 1, both the monitor (5) and keyboard (6) have been omitted).It should clearly appear that the invention requires no physicalmodifications of Terminal (1), nor of any of the applications related toit. The only required modifications are specified in the following.

According to an initial and important characteristic of this invention,all or part of the flow of data between Terminal (1) and the network(RI) travels through the smart card, henceforth referred to as (2 a).The flow of data however continues to travel through access circuits tonetwork (11). As previously explained, given the state of the art, smartcards cannot be directly connected to a network, and in particular ofthe type Internet.

Access circuits (11) are connected to smart card (2 a) via abi-directional transmission channel, represented by two serial links (21a). Similarly, smart card (2 a) is connected to the terminal and, inparticular, navigator (10) via a bi-directional transmission channel,which is represented by two serial links (22 a).

More specifically, channel (21 a) and channel (22 a) are disjointed andbi-directional from a logical point of view. Specific software layers(13) and (23 a), which will be described in detail later, allow, inparticular, using a unique physical connection, of the type termed“half-duplex” according to current state of the art, two analogchannels, (21 a) and (22 a) to be obtained.

To obtain such a function, smart card (2 a) is specific to theinvention. This specificity does not pertain to physical structure, atleast not to the external configuration of the card and the chip (notshown in FIG. 2). Location of the latter depends on a series of norms aswell as physical interfaces (input-output meters, etc.) and electricalconstraints (type of signal etc.).

However, as will be demonstrated later in greater detail, numerousapplications (not shown) can be installed on smart card (2 a).Additionally, a layer of specific communication protocol needs to beinstalled, which is represented in FIG. 2 by (23 a).

In a symmetrical way, on Terminal (1), provisions are required forinstallation of a layer of specific protocol, schematically representedas (13), functioning as a counterpart to the specific layer instance ofsmart card (2 a).

The architecture that has been outlined above allows, in particular, toprocess all functions linked to communication security from within smartcard (2 a): authentication, etc. Data remains secret and confined to thesmart card (2 a) circuits and are thus no longer sent to terminal (1).

According to another important characteristic of this invention, smartcard (2 a), supplies the host system, that is, Terminal (1), with avirtual model. For this purpose, according to a preferred application,smart card (2 a) functions as a “WEB” server.

Smart card (2 a) is “addressed” by navigator (10). It sends a “WEB” typepage in “HTML”, an “applet” or any other kind of software item. As anexample, the “WEB” page may be displayed as a home page supplyingvarious application options and/or hyperlinks to outside servers.

In practice, smart card (2 a) is advantageously “addressed” by a “URL”(Universal Resource Location) address, which feeds back to Terminal (1)itself, rather than pointing to an outside server. As an example, thestructure of a “URL” usually is as follows:

http://127.0.0.1:8080  [1]

wherein 127.0.0.1 corresponds to the feedback “IP” address and 8080corresponds to port identification.

FIG. 3A schematically illustrates this procedure. On a hypotheticalbasis, in response to a query by navigator (10), smart card (2 a)displays a page P in “HTML”, a page displayed, for example, onvisualization component (5) of Terminal (1). Page P, defined as a homepage, may display, as customary, various graphic or text elements, butalso comprises several hyperlinks to outside servers, Hl₁, Hl₂, . . . ,Hl_(j) to Hl_(n), where “j” and “n” are arbitrary numbers and “n”represents the maximum number of possible choices. It is obviouslydependent upon smart card (2 a) being inserted in reader (3). Choicesoffered may depend on those rights, which have been granted to the smartcard (2 a) user: subscription to services, level of access, etc. Theprocedure, which is described, uses part or all of standardcommunication layers (not shown), as well as specific layers (13) and(23 a), in a way that will be specified in detail later.

Each hyperlink, for example hyperlink Hl_(j), points to an outside “URL”resource. This communication and data exchange procedure betweenTerminal (1) and a server (4), connected to network (RI) and comprisingthe resource addressed by the “URL” associated to hyperlink Hl_(j), hasbeen illustrated in FIG. 3B. As an example, the “URL” structure mayappear as follows:

http://127.0.0.1:8081/www.NAME.com/index.html  [2]

wherein 127.0.0.1 corresponds to the “IP” address, 8081 corresponds toport identification, “NAME.com” corresponds to the an Internet companyor other kind of site, according to customary rules for naming suchsites, and “index.html” corresponds to the home page of the site inquestion. Instead, and in lieu of the extension “.com” customary forcommercial-type organizations, there are other extensions, such as “.fr”or “.gov”, which correspond to the location of the site on the Internetor to the type of organization.

The flow of data between Terminal (1) and addressed server (4) travelsthough smart card (2 a) and access circuits (11) to the network (RI)(for example, a modem). Smart card (2 a) processes, in particular, allproblems, which are linked to security of communication: authentication,data verification and filtering, etc. As previously mentioned, bothstandard communication protocols and specific communication protocols(13, and 23 a) are used.

According to another aspect of this invention, smart card (2 a) iscapable of authorizing direct data exchange between navigator (10) or,in general, between Terminal (1) and network (RI) and the addressedserver (4). This procedure is illustrated schematically in FIG. 3C.Obviously, all data exchange occurs via access circuits (11) to network(RI). Concerned data advantageously corresponds to data that has noimpact on security, such as page backgrounds, icons, etc., or text thatis “nonsensitive” or non-confidential.

It follows from those specific features of this invention, outlinedabove, that Terminal (1) becomes all-purpose and supports numerousapplications. Additionally, when certain applications require aparticular communication protocol, smart card (2 a) can supply Terminal(1) with programs, in “JAVA’ script format, for example, which provideinstructions for use.

In the following, in accordance with FIG. 4, a more detailed descriptionof a sample architecture for application based on the smart card of thisinvention is provided.

With the exception of communication protocol software layers (13) and(23 a), which are specific to this invention, each installed in Terminal(1), and smart card (2 a), the other components, physical or software,are all well known to the state of the art.

Terminal (1) comprises access circuits (11) to network (RI) consisting,for example, of a modem for Internet access or a network card for localnetwork access. These circuits group lower software layers C₁ and C₂corresponding to previously mentioned “physical” and “data links”layers.

Higher layers C₃ and C₄ have also been represented corresponding to“network addressing” (“IP” for the case of the Internet) and “transport”(“TCP”). The higher application layer (“http”, “ftp”, “e-mail”, etc.)has not been represented.

Interface between lower layers C₁ and C₂ and higher layers C₃ and C₄consists of a software layer (15), generally referred to as “lower layerdriver”. Higher layers, C₃ and C₄, rely on this interface and areimplemented via libraries of specific functions and network libraries(14), to which they each correspond. For the case of the Internet,“TCP/IP” is implemented via libraries, termed “sockets”.

In FIG. 2, this organization allows navigator (10) to send queries toserver (4) for consultation of “WEB” pages (protocol “HTTP”), for thetransfer of files (protocol “FTP”) or for sending electronic mail(protocol “e-mail”).

Terminal (1) also comprises smart card reader (3), integrated or not. Tocommunicate with smart card (2 a), the card reader also encompasseslower layers CC₁ (physical layer) and CC₂ (data link layer), whichfunction in ways similar to layer Cl and layer C₂. Software interfacesbetween layer CC₁ and layer CC₂ are described, for example, viaspecification “PC/SC” (“part 6, service provider”). As for layer CC₁ andlayer CC₂, these are specifically described in ISO norms 7816-1 to7816-4.

According to the state of the art (and also in this invention), anadditional software layer (16) constitutes the interface betweenapplication layers (not shown) and lower layers CC₁ and CC₂. The mainfunction delegated to this layer consists of multiplexing/demultiplexingfunctions.

Communication with smart card (2 a) occurs according to a paradigm thatis similar to that which is used for the manipulation of files in a“UNIX” (Copyrighted) type operating system: OPEN, READ, WRITE, CLOSEetc.

A similar organization exists for smart card (2 a), that is, thepresence of two lower layers CCa₁ (physical layer) and CCa₂ (data linklayer), as well as an interface layer (26 a), quite similar to layer(16).

According to an important primary characteristic of this invention,provisions exist on both sides, that is, within terminal (1) and withinsmart card (2 a), for installation of specific communication protocollayers: (13) and (23 a) respectively.

In Terminal (1), layer (13) interfaces with “lower driver layers” (15)with libraries (14) of network layers C₃ and C₄ and with protocol layersof card reader (3), that is, with lower layers CC₁ and CC₂, viamultiplexing layer (16). Layer (13) allows the transfer of networkbundles to and from smart card (2 a). Additionally, it adapts toexisting applications, such as the Internet navigator (10) (FIG. 2),electronic mail, etc, for uses that invoke function of smart card (2 a).

A perfectly similar organization exists for smart card (2 a) consistingof an additional implementation of the specific layer (23 a) incounterpart to layer (13).

More particularly, specific layers, (13) and (23 a) have been subdividedinto three main software components:

a module, (130) or (230 a), for the transfer of information blocksbetween layers (13) and (23 a) via layers CC₁, CC₂, CCa₁ and CCa₂;

one or several software items (132) and (232 a), termed “intelligentagents”, which perform, for example, functions for protocol conversionand

one module for the management of a specific configuration, (131) and(231 a) respectively, a module that may be assimilated by a particularintelligent agent.

Thus, there exists, within Terminal (1) and within smart card (2 a) astack of communication protocols functioning between both entities. FIG.5 illustrates the communication protocol stack of smart card (2 a),given that the communication protocol stack for Terminal (1) presents asimilar structure.

Moving from lower to higher layers, there are layers CCa₁, CCa₂, 26 a,230 a, 231 a, 232 a, previously mentioned, as well as anapplication-level layer (24 a). It should be noted that smart card (2 a)can support several different applications.

Level 2 layers (data link layers) CC₂ and CCa₂ support exchanges betweensmart card (2 a) and Terminal (1). These layers are responsible fordetection and eventual correction of transmission errors. Differentprotocol options exist and the following, in particular, on anon-exhaustive basis:

recommendation ETSI GSM 11.11;

the protocol established by norm ISO 7816-3, in T=0 character mode;

the protocol established by norm ISO 7816-3, in T=1 block mode or

the protocol established by norm ISO 3309, in “HDLC” frame mode (meaning“High-Level Data Link Control procedure”.)

Within the framework of this invention, the preferred protocolcorresponds to ISO 7816-3, in block mode.

According to established methods, for each protocol layer there existseveral primitives that allow for the exchange of data between layerslocated at the same level and between each layer. As an example,primitives associated to level 2 layers are of the type “data-request”(“Data.request”) and “data-response” (Data.response) from the smartcard, as well as “data-confirmation” (“Data.confirm”), etc.

More specifically, according to this invention, layers (13) and (23 a)are in charge of the dialogue between smart card (2 a) and the host,that is, Terminal (1). These layers thus allow for exchange ofinformation between terminal (1) users (not shown) and smart card (2 a),for example, via scrolling hypertext menus in “HTML”, as demonstratedfor FIGS. 3A and 3B (for page P). These also allow a configuration to beset up that is adapted to sending/receiving data bundles.

As indicated above, these layers comprise three distinct entities.

The first layer (130) or (230) essentially consists of a logicmultiplexer. It allows for exchange of information between smart card (2a) and host terminal (1), occurring as protocol data units. It functionsin a way that is similar to a data bundle switch. These units are sentor received via level 2 layers (data link layers). This particularcommunication protocol allows communication to be established between atleast one pair of “intelligent agents”. The first agent (132) of eachpair is located in layer (13) on the side of terminal (1); the second(232 a) is located in layer (23 a) on the side of smart card (2 a). Alink between two “intelligent agents” is associated to each session. Asession is defined as an exchange of bi-directional data between thesetwo agents.

An intelligent agent is capable of performing all or part of layerfunctions at level 3 and 4, depending on the design configuration ofTerminal (1).

A particular intelligent agent is advantageously identified by aninteger, for example, out of 16 bits (an integer ranging between 0 and65535). This identification marker is used, for example, in a dataprotocol unit as a destination or source reference.

There are two major categories of intelligent agents: “server” typeagents, which are identified with a fixed reference and “client” typeagents, which are identified with a variable type reference, which issupplied by a specific layer (130) or (230 a).

The procedure required to open a session usually is the following: anintelligent agent of the type “client” opens a session towards anintelligent agent of the type “server”. Layers (130) and (230 a) managethe tables (not shown), which contain a list of those intelligent agentsthat are present on both the terminal (1) host and smart card (2 a)sides.

Intelligent agents are associated with a particular set of properties orattributes. On a non-exhaustive, exemplification basis, the followingsix properties are listed in association with intelligent agents:

“host”: agent located in the terminal;

“card”: agent located in the smart card;

“local”: agent that does not communicate with the network;

“network”: agent that communicates with the network;

“client”: agent that initializes a session;

“server”: agent that receives a session request.

For the case of the Internet, the main application targeted by thisinvention, client/server agents on the smart card side, perform clientand/or server protocols, which are described by a set of controlspecifications, known in Anglo-Saxon terminology as “RFC” (“Reserved forCommand”). As a non-exhaustive example, protocol “HTTP 1.1” correspondsto specification “RFC 2068”.

Intelligent agents allow for the exchange of data (in hypertext, forexample), however, they are also capable of launching networktransactions.

Configuration management modules (131) and (232 a) respectivelycorrespond to particular intelligent agents. For example, module (131),on the side of host Terminal (1), manages, in particular, allinformation relative to the configuration of the terminal (functioningmodes, as will be specified in greater detail for FIGS. 7A to 7D), listsof agents that are present, etc. Module (231 a), on the side of smartcard (2 a), comprises similar functions. Communication between both ofthese agents may be established in order to open a session.

Two examples corresponding to these procedures and in reference to FIGS.6A and 6B are described in the following.

FIG. 6A illustrates in box diagram format the architecture thatcorresponds to presentation of a virtual terminal to host terminal (1).This Figure outlines in detail the procedure that has been previouslydescribed in reference to FIG. 3A. Elements, which are common to thepreceding Figures, display identical references and are described anewonly as required.

The procedure, which is described, requires correspondence only betweena single pair of intelligent agents (132) and (232 a).

As previously mentioned, “WEB” navigator (10) present Terminal (1) sendsan “HTTP” query implying feedback on itself (see formula [1]). The queryis sent to layer C₄ (“TCP” transport layer), then to layer C₃ (“IP”network address layer). As the “URL” implies “IP” feedback addressing,the query is sent back to layer C₄, which forwards it to a specificlayer corresponding to intelligent agent (132). The latter opens asession with its counterpart in smart card (2 a), that is, withintelligent agent (232 a). It converts the “URL” into a format that isacceptable by layers (130) and (230 a). The exchange bi-directional datathen occurs via different stack layers: 130, 16, CC₂, and CC₁ forTerminal (1), and CCa₁, CCa₂, 26 a, and 230 a for smart card (2 a).

In response, intelligent agent (232 a) sends instructions and/or datacontained in application layer (24 a). The latter, as previouslymentioned, may appear as scrolling “WEB” page menus or in “HTML” format(FIG. 3A: P).

However, an “HTTP” connection with network (RI) implies cooperationbetween two pairs of intelligent agents. FIG. 6B illustratesschematically such a procedure in box diagram format. Elements, whichare common to preceding Figures, display identical references and aredescribed anew only as required.

The “URL” sent by the navigator is of the type previously described informula [2].

On the side of Terminal (1), an initial intelligent agent (1321) with“local”-type properties ensures exchanges between host Terminal (1) andan agent (232a₁), located on smart card (2 a), also bearing “local” typeproperties.

Similarly, a second intelligent agent (132 ₂) with “network”-typeproperties ensures exchanges between an agent (232a₂), located on smartcard (2 a), also bearing “network” type properties, and network (RI).

This connection establishes two sessions:

1/ host agent local 132 ₁ card agent local 232a₁;

2/ host agent network 132 ₂ Chard agent network 232a₂.

Layers (130) and (230 a) guarantee, in particular, all softwaremultiplexing/demultiplexing functions, in order to direct data from andto agents (132 ₁) and (232a₁), on the one hand, and from and to agents(132 ₂) and (232a₂), on the other.

For the first session, the flow of data travels through Terminal (1)layers: C₄, C₃, C₄, 13 (agent 132 ₁ and layer 130), 16, CC₂ and CC₁, andsmart card (2 a) layers: CCa₁, CCa₂, 23 a, (layer 230 a and agent232a₁), to reach application layer (24 a).

For the second session, the flow of data, originating from applicationlayer (24 a), travels through smart card (2 a) layers: 23 a, (agent232a₂, and layer 230 a), 26 a, CCa₂, CCa₁, and Terminal (1) layers: CC₁,CC₂, 16, 13, (agent 132 ₂, and layer 130), C₄ to C₁, prior to reachingnetwork RI.

Several configuration examples, in accordance with FIGS. 7A to 7D, willhenceforth be described in the following. Depending on both theparticular type of network considered and the terminal, the partition ofcommunication software layers can occur differentially. Elements, whichare common to both these Figures and the preceding ones, are displayedwith identical references and are described anew only as required.

FIGS. 7A and 7B illustrate schematically, in box diagram format, twoarchitectures that are more specifically adapted to a mode, termed“network partition”. According to this mode, the smart card and theterminal share the same address, for example, the same “IP” address,when network RI is of the type Internet. The final addressee of networkdata bundles is determined according to criteria that have beenpre-established.

FIG. 7A illustrates schematically an architecture with softwarepartition of one network layer. The Terminal (1 a) contains a networklayer C₃ (network addressing layer). Smart card (2 a) receives networkbundles addressed to the Terminal according to a set of specificparameters (sender address, etc.). Bundles are sent with the networkaddress of Terminal (1 a). As previously outlined, provisions exist forinstallation of two specific layers (13 a) and (23 a), located inTerminal (1 a) and smart card (2 a) respectively. Layers (16) and (26 a)(in FIGS. 6A and 6B) have not been represented.

FIG. 7B illustrates schematically an architecture with physicalpartition of a network layer. A physical device (7) is inserted betweennetwork (RI) and the (1 b). Device (7) permits receiving network bundlesaddressed to terminal (1 b), depending on a set of specific parameters(sender address etc.). Bundles are sent with the network address ofterminal (1 b). The physical device comprises, for example, twocommunication circuits, for example, of the type network cards (70) and(71), each consisting of two lower communication protocol layers C′₁-C′₂and C″₁-C″₂ respectively. The card or circuits (70) are linked tonetwork (RI). The card, or circuits (71) are linked to network accesscircuits (11) or, in general, to the communication card, which ispresent in terminal (1 b). Communication between network (RI) andTerminal (1 b) thus occurs via physical device (7), incorporatingspecific layer (13 b).

Physical device (7) is additionally connected to reader sub-system (3),integrated or not, for smart card (2 a). This reader sub-systemcomprises, as previously mentioned, layers CC₁ and CC₂. Similarly, smartcard (2 a) contains two lower layers CCa₁ and CCa₂ as well as specificlayer (23 a).

FIG. 7C schematically illustrates, in box diagram format, anarchitecture that is more specifically adapted to a functioning modetermed “bridge”.

According to this functioning mode, smart card (2 a) contains anindividual network address. The Terminal, (1 c) functions as an accessbridge from smart card (2 a) to network (RI). Specific layer (13 c), onthe side of the terminal, is located between layer C₃ (networkaddressing layer) and layer CC₂. As previously outlined, smart card (2a) comprises specific layer (23 a), the counterpart to layer (13 c).

FIG. 7D illustrates schematically, in box diagram format, anarchitecture that is more specifically adapted to a functioning modetermed “tunnel”.

According to this functioning mode, the terminal (1 d) cannot supply orshare a level 3 layer. The only possible method of communication betweensmart card (2 a) and network (RI) consists in establishing a “tunnel”where application data can travel and which is eventually translated bya protocol converter in the specific layer on the terminal side (13 d).Specific layer (13 d) is located between layers at level 4 (C₄) and anapplication layer (not shown). As previously outlined, smart card (2 a)comprises a specific layer (23 a), the counterpart to layer (13 d).

Characteristics of the terminal and/or possible configurations may beidentified by the smart card or conversely controlled by the latterusing primitives.

On a non-exhaustive, exemplification basis, an initial primitive,defined as:

“TerminalGetConfiguration.request”,

(to obtain the configuration) and sent by the smart card to theterminal, allows the request of characteristics of the terminal, as wellas all various possible configurations. The response to this query isobtained in a dual primitive:

“TerminalGetConfiguration.response”.

A second primitive, defined as:

“TerminalSetConfiguration.request”,

(control configuration) and sent by the smart card to the terminal,allows configuration of the terminal. The response to this command,traveling as a dual primitive:

“TerminalSetConfiguration.response”,

allows all information required for network transactions (networkaddress, configuration, etc.) to be obtained.

When a configuration is available, the smart card can send or receivedata, from and to network (RI). The data, which is exchanged between thesmart card and the terminal, consists of network bundles where theterminal offers such a possibility, or application data where the tunnelmode has been implemented (FIG. 7D).

Available applications on the host system of the smart card are capableof communicating with the smart card using protocol converters. Thisfunction is delegated to intelligent agents located in the specificlayers of the communication protocol.

On the terminal side, methods of communication between applications andintelligent agents may vary depending on the type of terminal and, inparticular, the type of operating system in use. On a non-exhaustive,exemplification basis, the following are listed:

“API”s (“Application Programmatic Interface”);

“DLL”s (“Dynamic Link Library”);

use of a feedback address, such as the aforementioned “URL” [1].

Finally, as illustrated schematically in FIG. 8, an intelligent agentAgS, termed server, may be integrated in an application Appli located inthe smart card. In this case, the associated reference identifiesapplication Appli. For example, use of an intelligent agent Agc, termedclient, stored in a library Bib, is possible via an “API”. In such aconfiguration, the server stores the keys and uses the services of theclient who knows the required communication protocol.

To summarize the preceding, a more detailed description is provided inthe following of the major steps invoked in the example of a completeimplementation:

1/ the smart card is inserted in the smart card reader connected to thehost terminal;

2/ the host terminal sends what is termed an acknowledgment token;

3/ the smart card receives terminal configuration via the aforementionedprimitive:

“TerminalGetConfiguration.request”

and, depending on the response, the smart card either initiates adialogue or, conversely, waits for a terminal query;

4/ the terminal receives an index of all functions present in the smartcard via a feedback “URL”: http://127.0.0.1:8080/index.html (see [1]),for a session of the type:

“HTTP Local Host Intelligent Agent Client specific layer 130 specificlayer 230 Local Card Intelligent Agent Server”.

5/ upon receipt, the user of the terminal selects one of the availableapplications;

6/ the user decides to connect to an outside server for which the smartcard supplies access;

7/ the navigator generates a “URL”, for example:

http://127.0.0.1:8080/www.NAME.com/index.html

(see [2]), sent to the smart card, via a protocol converter, in asession of the type:

“HTTP Local Host Intelligent Agent Client specific layer 130 specificlayer 230 Local Card Intelligent Agent Server”

8/ an invitation to enter a password then appears, using a sessionbetween two intelligent agents for data exchange, following which thepassword is sent to the smart card;

9/ the smart card verifies the validity of the password supplied duringthe preceding step, using security data stored within it;

10/ a specific configuration is defined for the terminal, and is appliedusing the aforementioned primitive “TerminalSetConfiguration.request”;

11/ the smart card connects to the selected application server,according to the specifications of the application;

12/ the user receives in response to his/her request (of the type“HTTP”) an acknowledgment or a file depending on the type of servicethat is implemented.

Following consideration of the above, it appears that the inventionclearly achieves that which it set out to accomplish.

As previously mentioned, it presents numerous advantages and, inparticular, the following: a high degree of security for communicationoccurring between the terminal and a network; all-purpose function ofthe terminal, which allows for support of numerous applications, withoutrequiring any modification of the physical parts of the terminal or ofthe applications running within it. All that is required is installationof a specific layer of communication software. It remains entirelycompatible with existing equipment and its implementation. It permitshigh user mobility and/or of the user terminal while retaining allcommunication security levels previously mentioned. Finally, it offershigh comfort levels, since users can, on any machine that accepts theirsmart card, find their own personal and customary work environment.Consequently, it is appropriate to speak of a “virtual home”.

It should be clear however, that this invention is not limited to thoseimplementation examples that have been explicitly described and, inparticular, with reference to FIGS. 2 to 8.

In particular, as previously mentioned, those architectures, whichimplement inventive procedures and, more specifically, the partitioningand distribution of communication protocol layers between the hostterminal and the smart card, may be diversified.

Similarly, examples of instruction and particular commands, as well asinterface modes, have been provided for the sole purpose of betterspecifying the characteristics of this invention, without restrictingapplications in any way.

It should also be clear that, while particularly well adapted toapplications termed securing (authentication, etc), the invention is notlimited exclusively to these kinds of applications. Numerousapplications may be stored in the smart card, with memory capacity ofthe latter, maximum data flow and the power of data processing circuits(microprocessor or microcontroller) functioning as the only limits. Infact, it should be observed that such limitations tend to lessen overtime, since these depend on technological development, whichparticularly rapid in this domain.

Finally, the network, to which the terminal may be connected, arediverse (local network, Internet, etc.). The same applies totransmission protocols: Internet-type protocols, compatible with MINITEL(Copyrighted), etc. While this invention has been described inconjunction with specific embodiments thereof, it is evident that manyalternatives, modifications and variations will be apparent to thoseskilled in the art. Accordingly, the preferred embodiments of theinvention as set forth herein, are intended to be illustrative, notlimiting. Various changes may be made without departing from the truespirit and full scope of the invention as set forth herein and definedin the claims.

What is claimed is:
 1. A method of communication between a terminal anda smart card, said terminal being operatively connected to a smart cardreader for communicating with the smart card and a data transmissionnetwork (RI), said terminal comprising a first network (RI) accessprotocol stack, comprising a specified number of communication softwarelayers (C₁-C₄), and said smart card and smart card reader comprising asecond protocol stack and a third protocol stack, each comprising atleast lower order software communication layers (CC₂-CC₁, CCa₂-CCa₁), toallow data exchange between the smart card and said terminal, saidmethod comprising establishing a first preliminary phase, an interfaceby a first specific software item in smart card for said lower ordercommunication layers (CCa₂-CCa₁) of the third protocol stack with atleast one application registered in the smart card, establishing asecond preliminary phase, which consists of installing, in the terminal,a second specific software item, which functions as an interface withsaid lower order communication layers (CC₂-CC₁), of the second protocolstack and with specified layers of said first protocol stack (C₂, C₃),wherein said first and second specific software items in additioncomprise at least one pair of primary coupled software entities, each ofsaid entities cooperating with each other in order, and establishing asession for a bi-directional data exchange between at least one of saidterminal and said smart card, and said data transmission network (RI),so that all or part of said data travels through said smart card.
 2. Themethod of claim 1, wherein said specific software items comprise twoadditional entities consisting of a data transfer module, whichfunctions as an interface for said lower layers (CC₂-CC₁, CCa₂-CCa₁) ofthe second and third protocol stacks and a management module, and inwhich said primary entities of each pair are constituted by intelligentagent software modules, establishing said sessions.
 3. The method ofclaim 2, wherein said intelligent agents are clients, which open saiddata exchange sessions and servers, which supply said data.
 4. Themethod of claim 2, wherein said intelligent agents are associated withat least one of the following attributes: an initial attribute termed“host”, indicating that the intelligent agent is located in saidterminal; a second attribute termed “card”, indicating that theintelligent agent in located in said smart card; a third attributetermed “local”, indicating that the intelligent agent is notcommunicating with said network (RI); a fourth attribute termed“network”, indicating that the intelligent agent is communicating withsaid network (RI).
 5. The method of claim 2, further comprisingestablishing a session between a pair of predetermined said agents, soas to send to said terminal data from an application, registered in saidsmart card, said data consisting of a list (P) of applications, afteraccess is authorized by the user of the terminal.
 6. The method of claim5, wherein said network (RI) is a global network and said terminalcomprises a navigator for said network, said data consisting of a page(P) written in hypertext language consisting of hyperlinks (Hl₁-Hl_(n)),pointing to resources located on various servers outside of terminal,further comprising utilizing said navigator for the selection of saidhyperlinks (Hl_(i)) and generating a particular address, activatingpredetermined intelligent agents, and launching sessions for theexchange of data between the terminal and smart card and the terminaland said global network (RI), in order to reach a selected server,wherein all or part of said data traveling through said smart card. 7.The method of claim 5, wherein generating of the particular address ofthe said smart card by the network navigator occurs via a feedbackaddress to said terminal.
 8. The method of claim 6, further comprisingthe step of identifying said user and filtering data received and sentfrom and to said network (RI) using secret data located in said smartcard, wherein said step of identifying and filtering occurs within smartcard.
 9. The method of claim 2, further comprising a step ofestablishing a data transfer session between a pair of saidpredetermined agents, to send to terminal data from an application,registered with said smart card, and configuring the terminal by saiddata according to a predetermined virtual model, so that saidapplication may be executed from within terminal.
 10. The method ofclaim 1, further including storing a plurality of applications in thesmart card.
 11. A method of communication between a terminal and a smartcard, said terminal being operatively connected to a smart card readerfor communicating with the smart cards and a data transmission network(RI), said terminal comprising a first network (RI) access protocolstack comprising a specified number of communication software layers(C1-C4), said smart card and smart card reader comprising a secondprotocol stack and a third protocol stack, each comprising at leastlower order software communication layers (CC2-CC1, CCa2-CCa1), to allowfor data exchange between the smart card and said terminal; said methodcomprising establishing in a first preliminary phase an interfacebetween a first specific software item and said lower ordercommunication layers (CCa2-CCa1) of the third protocol stack whichconsists of installing, in the smart card, the first specific softwareitem, which functions as an interface for said lower layers (CCa2-CCa1)of the third protocol stack and at least one application registered inthe smart card; establishing a second preliminary phase, which consistsof installing, in the terminal, a second specific software item, whichfunctions as an interface for said lower layers (CC2-CC1) of the secondprotocol stack and with specified layers of said initial protocol stack(C2, C3), wherein said first and second specific software items inaddition comprise at least one pair of primary coupled softwareentities, each of said entities adapted to cooperate with each other,and; establishing a bi-directional data exchange session between saidterminal and said smart card, so that said smart card supplies saidterminal with a pre-determined virtual terminal model, therebytransforming said smart card into at least one of a server and a client.12. The method of claims 11, wherein at least one of said server andclient is mobile and portable.
 13. The method of claim 11, wherein saidspecific software items comprise two additional entities consisting of adata transfer module, which functions as an interface for said lowerlayers (CC₂-CC₁, CCa₂-CCa₁) of the second and third protocol stacks anda management module and in which said primary entities of each pair areconstituted by intelligent agent software modules, establishing saidsessions.
 14. The method of claim 12, wherein said specific softwareitems comprise two additional entities consisting of a data transfermodule, which functions as an interface for said lower layers (CC₂-CC₁,CCa₂-CCa₁) of the second and third protocol stacks and a managementmodule and in which said primary entities of each pair are constitutedby intelligent agent software modules, establishing said sessions. 15.The method of claim 13, wherein said intelligent agents are clients,which open said data exchange sessions and servers, which supply saiddata.
 16. The method of claim 14, wherein said intelligent agents areclients, which open said data exchange sessions and servers, whichsupply said data.
 17. The method of claim 13, wherein said intelligentagents are associated with at least one of the following attributes: aninitial attribute termed “host”, indicating that the intelligent agentis located in said terminal; a second attribute termed “card”,indicating that the intelligent agent in located in said smart card; athird attribute termed “local”, indicating that the intelligent agent isnot communicating with said network (RI); a fourth attribute termed“network”, indicating that the intelligent agent is communicating withsaid network (RI).
 18. The method of claim 14, wherein said intelligentagents are associated with at least one of the following attributes: aninitial attribute termed “host”, indicating that the intelligent agentis located in said terminal; second attribute termed “card”, indicatingthat the intelligent agent in located in said smart card; a thirdattribute termed “local”, indicating that the intelligent agent is notcommunicating with said network (RI); a fourth attribute termed“network”, indicating that the intelligent agent is communicating withsaid network (RI).
 19. The method of claim 13, further comprisingestablishing a session between a pair of predetermined said agents, soas to send to said terminal data from an application, registered in saidsmart card, said data consisting of a list (P) of applications, afteraccess is authorized by the user of the terminal.
 20. The method ofclaim 14, further comprising establishing a session between a pair ofpredetermined said agents, so as to send to said terminal data from anapplication, registered in said smart card, said data consisting of alist (P) of applications, after access is authorized by the user of theterminal.
 21. The method of claim 13, further comprising a step ofestablishing a data transfer session between a pair of saidpredetermined agents, to send to terminal data from an application,registered with said smart card, and configuring the terminal by saiddata according to a predetermined virtual model, so that saidapplication may be executed from within terminal.
 22. The method ofclaim 14, further comprising a step of establishing a data transfersession between a pair of said predetermined agents, to send to terminaldata from an application, registered with said smart card, andconfiguring the terminal by said data according to a predeterminedvirtual model, so that said application may be executed from withinterminal.
 23. The method of claim 11, further including storing aplurality of applications in the smart card.
 24. A system ofarchitecture for communication between a terminal, and a smart cardcomprising a smart card reader, a smart card communicating with thesmart card, a smart card, a data transmission network (RI), saidterminal having a first protocol stack for network (RI) access, saidfirst stack comprising a determined number of communication softwarelayers (C₁-C₄), said smart card comprising a second protocol layer and athird protocol layer, each comprising lower order communication softwarelayers (CC₂-CC₁, CCa₁-CCa₂), for data exchange between the smart cardand said terminal, and said smart card further comprising a firstspecific software item, which functions as an interface for said lowerlayers (CCa₂-CCa₁) of the third protocol stack and with at least oneapplication registered in the smart card, terminal having a secondspecific software item, which functions as an interface with said lowerlayers (CC₂-CC₁) of the second protocol stack and with determined layersof the said first protocol stack (C₂, C₃), wherein said first and secondspecific software items are adapted to cooperate with each other, toallow for the establishment of a bi-directional data exchange sessionbetween at least one of said terminal and said smart card, and saidnetwork (RI), so that all or part of said data travels through saidsmart card.
 25. The architecture of claim 24 further comprisingcommunication circuits connected to said network (RI), said secondspecific software item, is located on a side of terminal between lowerlayers (C₁-C₂), contained in said communication circuits, and higherlayers (C₃, C₄) of said first protocol stack, so that said terminal andsaid smart card can share the same address on network (RI), controlledby the second specific software item, on the side of the terminal. 26.The architecture of claim 25, wherein an additional physical device, islocated between said network (RI) and said terminal, said additionalphysical device comprising first and second communication circuits, eachconsisting of two lower communication protocol layers (C′₁-C′₂,C″₁-C″₂), the first circuits being connected to network (RI) and thesecond circuits being connected to said communication circuits of theterminal, the additional physical device being connected to said readerof smart card, and said specific software item, on the side of theterminal, is located within said additional physical device, andfunctions as an interface between said lower layers (C′₁-C′₂, C″₁-C″₂)of said first and second communication circuits and lower layers (CC₁,CC₁) of reader of smart card, so that the terminal and smart card canshare the same address on network (RI), while controlled by specificsoftware item, on the side of the terminal.
 27. The architecture ofclaim 26, wherein said communication circuits are connected to saidnetwork (RI), said specific software item, on the side of terminal,functions as an interface between said lower layers (CC₁, CC₂) of saidsecond protocol stack and is located between layers at higher levels(C₃, C₄) of said first protocol stack, so that said smart card with anaddress that is different from terminal on network (RI), terminalfunctions for smart card as an access bridge to network (RI), whilecontrolled by specific software item of terminal.
 28. The architectureof claim 27, wherein said communication circuits are connected to saidnetwork (RI), wherein said specific software item on the side ofterminal functions as an interface between said lower layers (CC₁, CC₂)of said second protocol stack and is located between one layer of saidfirst protocol stack at a higher level 4 (C₄), and one application layerso that the flow of application-type data is authorized between saidsmart card and said terminal.
 29. A system of architecture forcommunication between a terminal, and a smart card comprising a smartcard reader for communication with the smart card, a data transmissionnetwork (RI), said terminal having a first protocol stack for network(RI) access, said first stack comprising a number of communicationsoftware layers (C₁-C₄), and said smart card reader, and said smart cardhaving a second protocol stack and a third protocol stack, eachcomprising lower order software communication layers (CC₂-CC₁,CCa₂-CCa₁), for allowing data exchange between the smart card and saidterminal, said smart card having a first specific software item, whichfunctions as an interface with said lower layers (CCa₂-CCa₁) of thethird protocol stack and with at least one application registered in thesmart card, said terminal having a second specific software item, whichfunctions as an interface with said lower layers (CC₂-CC₁) of the secondprotocol stack and with determined layers of the first protocol stack(C₂, C₃), wherein said first and second specific software items areadapted to cooperate with each other in order to establish abi-directional data exchange session between said terminal and saidsmart card, whereby said smart card supplies said terminal with apredetermined terminal virtual model, which transforms said smart cardinto at least one of a server and a client.
 30. The architecture ofclaim 29, wherein said server and/or client is both mobile and portable.